Summary

Total Articles Found: 1

Top sources:

Top Keywords:

Top Authors

Top Articles:

  • CORS is such a mess. What are current best practices?

CORS is such a mess. What are current best practices?

Published: 2023-03-30 11:54:28

Popularity: None

Author: losvedir@users.lobste.rs (losvedir)

Keywords:

  • browsers
  • security
  • I’m looking into implementing CORS (again, it seems like this is something that comes up every few years, and every few years I have to re-orient myself about how it all works), and as always it’s so confusing. (Here I’m talking about Access-Control-Allow-Origin type stuff, primarily, as CORS was initially a structured way to relax the same-origin policy on requests. I’m not as familiar or concerned with some of the newer headers for mitigating Spectre-type attacks. Should I be?) Any CORS experts out there with “best practice” recommendations? The security and threat model is so counterintuitive. Is the whole point of the CORS model basically to handle the browser’s decision to send cookies on every request? If the browser just refused to send cookies by default on non-same-origin requests and prompted the user to “Allow Once” or “Allow Always” like it does for saving passwords, wouldn’t that also solve the problem (and not to mention CSRF as well, which CORS doesn’t address). The server needs to handle arbitrary traffic from arbitrary clients, so resources should be protected appropriately. The only thing particularly unique about the browser is that it chooses to send cookie credentials, possibly against the user’s intentions. With all that in mind, it seems like these are maybe best practices (somewhat counterintuitively): When possible always set Access-Control-Allow-Origin: *. Everywhere online seems to recommend not including the header, if it’s not necessary, or being as specific as possible with the origins you allow and validating against a regex or an allowlist. But, since ACAO * does not allow credentials, then that’s actually safer, right? And if your backend has to expect traffic from, say, curl, or whatever, then you might as well acknowledge that fact fundamentally and say arbitrary JS scripts out there can also hit the endpoint (as long as, similarly to curl, they don’t include a cookie). Is there a downside to this approach? Access-Control-Allow-Credentials: true - this is the truly dangerous one, since the whole threat model of CORS is about a malicious website sending an authenticated request to your server without the user’s consent. So in this case, you do need to carefully set ACAO to specifically the origin that your own real site is at. What should you do about CORP, COEP, etc - all the new headers?

    ...more

    end